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Description 

The invention is in the field of data processing 
and is specifically directed to a software copy protec- 
tion mechanism. In particular a mechanism is provid- 
ed which restricts software, distributed on magnetic 
disk or other medium, to use on any computer which 
is associated with a specified, physically secure co- 
processor where the mechanism does not interfere 
with the user creation of "backup" copies, but the pro- 
tection is not compromised by any such "backup" cop- 
ies. 

A good description of the background art to the in- 
vention is provided in the applicants EP-A-0 174 472. 

In addition to the prior art identified in the refer- 
enced application, Uchenick U.S. Patent No. 
4,458,315 suggests a security procedure for protect- 
ing software in which the software is distributed with 
a key number (first key information). In order for the 
software to be run on a computer, the computer must 
have access to a device storing "second key informa- 
tion". The program will not properly execute unless 
the first and second key information bears some spe- 
cified relation. The patent however does not describe 
use of a transaction token which forms an important 
component of the present invention, nor is there any 
apparent impediment to deter a pirate from merely al- 
tering the software so it can execute without this com- 
parison step nor does the patent describe how the 
computer obtains access to the "record key informa- 
tion" in such a way that that access cannot be dupli- 
cated or forged. 

Best, in U.S. Patents 4,168,396; 4,278,837 and 
4,465,901, describes a program protection mecha- 
nism which makes use of enciphered programs. How- 
ever, Best suggests that each copy of a program be 
customized so that it is only executable on a single mi- 
croprocessor, i.e. in a single, physically unique micro- 
processor, i.e. in a single, physically unique micropro- 
cessor. This protection appears breakable by discov- 
ering the key needed to decrypt the software and by 
other cryptanalytic techniques. However, as a practi- 
cal technique for protecting software, it is unusable. 
A software vendor must sell each copy of his software 
(which has been customized), along with the micro- 
processor which has been customized to run the as- 
sociated software. The only alternative is for the ven- 
dor to identify which microprocessor the user owns so 
that the software can be customized for it. To the ex- 
tent that the software vendor allows the software to 
be run on a class of microprocessors (say all 80286), 
then the protection is lost, for duplicates of the soft- 
ware will freely run on all microprocessors of the 
class. 

EP-A-0 191 162 discloses a cryptographic meth- 
od wherein each copy of the program is encrypted 
with a key unique to that copy. The user of the pro- 
gram has a password unique to that user. The user's 



password may be implemented in a smart card or as 
a password entered at a keyboard. Each copy of the 
program is unique. 

The referenced EP-A-0 174 472 describes a 

5 method for recording data on magnetic media in such 
a way that the act of reading the data alters it. Such 
"read once" magnetic recordings cannot be created 
by conventional disk drives so they cannot be copied 
by conventional personal computers systems. As de- 

10 scribed in the referenced application a computer is 
associated with a physically and logically secure co- 
processor and software as distributed on the magnet- 
ic media includes at least a significant section or por- 
tion which is encrypted. The magnetic media also in- 

15 eludes an encrypted decryption key which must be 
used by the coprocessor to decrypt the encrypted 
portion of the software. The act of transferring the en- 
crypted decryption key from the magnetic media to 
the secure coprocessor is linked to the mechanism 

20 which alters the data. This assures that, in the ab- 
sence of extraordinary measures, the encrypted de- 
cryption key is not transferable once the magnetic 
medium has been read. This prevents the creation of 
copies of the distribution medium which can be em- 

25 ployed on other computers, subverting the copy pro- 
tection mechanism. Once the coprocessor has ac- 
cess to the encrypted decryption key, it can decrypt 
this key. In the course of executing the software the 
encrypted portion is decrypted by the coprocessor. 

30 This ensures that the software is executable, but pre- 
vents the user from obtaining access to the complete 
software package in decrypted form. 

The mechanism described in the referenced ap- 
plication is extremely resistant to attack because the 

35 decryption key and the protected fraction of the soft- 
ware are never exposed to the user in unencrypted 
form. The owner of the software is allowed unlimited 
backup copies, but these backup copies are useless 
on any other personal computer (one which does not 

40 have access to the specific coprocessor already stor- 
ing the decryption key). The protection system is 
open to any software writer for use and any hardware 
producer for manufacture because it requires no shar- 
ing of confidential information (key information) be- 

45 tween the involved parties and its methods may be 
disclosed publicly without compromising its security. 

However the read once magnetic recording has 
two vulnerabilities in a copy protection system. First 
it is always possible (although costly) to examine the 

50 magnetic medium and produce a device which will 
forge its behavior to a computer system. Second, a 
determined pirate may be able to build an apparatus 
which will restore the pre-read state of the "read once" 
recorded data that has been used to authorize the ac- 

55 ceptance of a decryption key by a system. The re-ini- 
tialized medium could then be used to illicitly "author- 
ize" a second system. 

The method, as described in the referenced ap- 
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plication requires use of a public key crypto system. 
This architectural restriction limits the flexibility of the 
system. In addition the system described in the refer- 
enced application requires the use of a bus slot which 
may not be available on some systems or may be too 
valuable to a user. This is necessary to allow the co- 
processor to observe the host processor bus opera- 
tions so that it may assure itself that the appearance 
of the read once magnetic recording is not being 
simulated by a program on the host computer. 10 

The present invention overcomes the above not- 
ed disadvantages in that it firstly does not require a 
dedicated bus slot for a physically secure coproces- 
sor, it does not rely on public key crypto systems nor 
does it rely on read once magnetic media. In these re- 15 
spects it is both more versatile and more resistant to 
attempted piracy than the earlier system. 

The present invention is based on the recognition 
that today's software distribution techniques distrib- 
ute to the user, in addition to the software itself, the 20 
right to execute that software. That is, more particu- 
larly, when software is sold to the typical user, the 
user acquires not only the software itself but the right 
to use it. However, he can, with a typical personal 
computer, duplicate the software and distribute it 25 
along with the (implied) right to use it to others. The 
invention seeks to separate the software, from the 
right to use it. Further, it seeks to place the means of 
creating these Rights-to-Execute in the hands of the 
software authors or their representatives. It also 30 
seeks to do these things with no perturbation to the 
existing or planned channels of software distribution 
and minimum change to the means by which software 
is prepared for distribution. As will be described be- 
low, in accordance with the present invention, the typ- 35 
ical software purchaser may still duplicate at will the 
software he has received from the vendor. However, 
he cannot duplicate the right to use the software; in 
fact he receives a single right to use the software. To 
become effective, that right to use must be installed 40 
in a suitable coprocessor, and it is only when the right 
to use is installed on the suitable coprocessor (which 
is associated with the host computer on which the 
user intends to run the software) that the software be- 
comes executable. Other copies of the software that 45 
the user might make are not executable on any other 
host computer (even is such other host computer is 
associated with another suitable coprocessor). 

In accordance with the present invention soft- 
ware can be distributed on magnetic media (such as 50 
tape or floppy disk) or by other means (telephone 
lines, cable or broadcast transmission). The software 
is partitioned into an encrypted portion, P ft and an un- 
encrypted (clear text) portion P c . The choice of the 
partitioning is made by the software vendor with the 55 
understanding that only the encrypted portion will be 
protected from piracy. The encrypted portion, P e , of 
the software will be decrypted and executed by a 



physically and logically secure coprocessor if the co- 
processor possesses the decryption key which em- 
bodies the right to execute. The protected part of the 
software is, thus, never exposed in plaintext form and 
5 never executed by unauthorized systems. The copro- 
cessor may be attached to the user's personal com- 
puter either on the system bus or through a I/O or 
other communication port. 

In order to be effective, and decrypt the encrypt- 
ed portion of the protected software, the coprocessor 
must be provided with the decryption key (Right-to- 
Execute or RTE, also referred to as AK or Application 
Key) needed to render the encrypted portion of soft- 
ware executable. The key (RTE or AK) must be trans- 
ferred to the software owner's coprocessor in such a 
way that the transfer mechanism cannot be reused or 
reproduced by a user and thus grant key transfer to 
other personal computers. This is accomplished by 
associating the effective transfer of the decryption 
key into the no rv volatile memory of the coprocessor 
with a transaction token, e.g. the presence of the 
transaction token is required to effectively transfer 
the decryption key to the coprocessor. The token is 
very resistant to forgery for reasons which are descri- 
bed below and its information content is destroyed 
during the transfer transaction. The token has infor- 
mation content which is known to the coprocessor be- 
cause it is identified in an encrypted file. This file is 
called the Encrypted Token Description or ETD. This 
identification is authenticated to the coprocessor by 
the fact that it is encrypted with the same key (AK) 
which the software vendor has used to encrypt the 
protected portion of the software. The ETD may be 
distributed to the user by placing it in a dedicated reg- 
ister in the token, by recording it on the distribution 
medium, or by distributing it by other means. 

The software vendor supplied key (AK) is made 
available to the coprocessor by supplying it, in en- 
crypted form, with the program via the software dis- 
tribution medium or other means as described in the 
case of the ETD. In the general case, the key used to 
encrypt the AK is selected from a list of Coprocessor 
Supervisor Keys (CSKs) which is stored in all copro- 
cessors supplied by a given vendor. 

The function of encrypting the software vendor's 
decryption key with one of these stored encryption 
keys is a service provided by the coprocessor so that 
the store of keys (CSKs) need never be exposed to 
the software vendor. The coprocessor which the soft- 
ware vendor uses to encrypt the software vendor's 
keys may be precisely the same type of coprocessor 
as the user employs to decrypt and run the software. 
Alternatively, special processors may be sold for this 
purpose or standard processors may be enabled to 
perform this function by an encrypted message from 
the hardware manufacturer. These options may be 
useful in giving flexibility to the marketer of such de- 
vices. 
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For the same reason the software vendor's de- 
cryption keys (such as AK) are never exposed to the 
software user, the hardware vendor's encryption 
keys (CSK) are never exposed to the software ven- 
dor. This system thus has the property that no infor- 5 
mation need be shared between hardware and soft- 
ware manufacturers in order to use the protection pro- 
vided. In addition, a single encryption system such as 
DES may be used for all cryptographic functions. 

In accordance with the invention, in order to ac- w 
cess the transfer token, the coprocessor is provided 
with a data path which allows communication with a 
hardware sub-system such as a cartridge. This data 
path may utilize a connection to the cartridge sup- 
plied by either the host (such as a PC) or the copro- is 
cessor. The cartridge contains an electronic memory 
with properties that change (in a manner to be descri- 
bed) in response to whether the memory is being read 
from or written to. This cartridge sub-system must be 
extremely difficult to copy in the sense that a substi- 20 
tute is very unlikely to be created by a user which can 
fool a coprocessor into accepting it as verification of 
the user's right to store a given decryption key (AK) 
in the user's coprocessor. Since the connection to the 
sub-system is physically exposed, the transaction 25 
which uses this connection as its communications 
medium must be forgery-resistant. 

To be forgery-resistant, each transaction must be 
effectively unique and verifiable by the coprocessor. 
The technique by which this security is obtained is de- 30 
scribed below. 

The sub-system which is used to verify the right 
of a user to a particular decryption key is referred to 
as a transfer token. The necessary functions can be 
implemented using programs executed by a micro- 35 
processor or by using a dedicated hardware system. 
Inasmuch as the most economical implementation of 
a transfer token will be a dedicated hardware system, 
this is the version that is described. 

The transfer token hardware and its information 40 
content must be kept physically secure to avoid its ac- 
cess by the user through means which bypass the for- 
gery prevention feature. One implementation of this 
physical security is described in EP-A-0 268 882, the 
disclosure of which is incorporated by this reference. 45 
The same technique may be employed to render the 
coprocessor itself physically secure and to protect its 
memory contents from its exposure to a user. Since 
tokens can be implemented as a single, continuously 
powered, integrated circuit chip, no additional physi- 50 
cal security is needed. If the physical security of a tok- 
en were broken, then no cryptographic keys would be 
revealed and only the single associated software 
package could be redistributed. 

Thus, in accordance with the invention, software 55 
to be protected is partitioned into a plain text portion 
and an encrypted portion; the encryption key (AK) 
used to encrypt the software is known only to the 



software vendor. The protected software provided to 
the user is associated with the software decryption 
key, in encrypted form (EAK). The software decryp- 
tion key (AK) is encrypted with the hardware vendor's 
encryption key (CSK) which is not known to the soft- 
ware vendor. This encryption is a service performed 
by such coprocessors. The software and encrypted 
decryption key (EAK) may be associated with infor- 
mation describing a transfer token (TOKEN DATA) by 
encrypting that description under AK. The correspon- 
dence between the content of the token and the token 
data (after decryption under AK) indicates to the co- 
processor that that particular AK may be stored for f u- 
ture use. The authorized user is provided with a tok- 
en, which in a preferred embodiment is implemented 
in the form of a hardware cartridge. The transfer tok- 
en is physically and logically secure, so that a suffi- 
cient fraction of its information contents is not avail- 
able to the user. The transfer token, or the hardware 
cartridge incorporating the transfer token has a read 
once feature whereby the first time the hardware car- 
tridge is read the contents are altered so that the au- 
thorization which the hardware cartridge represents 
cannot be effectively reused by the user. The user is 
also provided with a physically and logically secure 
coprocessor. The physically and logically secure co- 
processor has in permanent memory the hardware 
vendor's decryption key(s) CSK1, CSK2, etc. The 
data descriptive of the token will typically be transfer- 
red with the software. 

The first time the user attempts to employ the 
protected software, he couples the physically and 
logically secure coprocessor to the computer system 
in which the protected software is to be run and also 
couples the hardware cartridge containing the trans- 
fer token to the computer system. 

On the f irst runn ing of the software the encrypted 
software key EAK is transferred to the coprocessor 
and is decrypted by the coprocessor using the re- 
quired CSK to obtain AK. For reasons which are ex- 
plained below, this transfer is temporary, the copro- 
cessor will reject the transfer if the conditions descri- 
bed below are not met. A verifiable portion of the con- 
tents of the hardware cartridge, i.e., the transfer tok- 
en, is also transferred to the coprocessor using a for- 
gery-resistant query/response protocol; this process 
alters or destroys the contents of the hardware car- 
tridge. The information revealed to an observer of the 
query and the response is insufficient to allow a for- 
ger to construct a correct response to another copro- 
cessor query. The transfer token can be "refilled" with 
information by a software author, but the refilled 
transfer token will only authorize a coprocessor to ac- 
cept an AK from that author. The physically and logi- 
cally secure coprocessor determines whether or not 
the transfer token is effective by determining whether 
or not it corresponds to an expected transfer token. 
Assuming the transfer token is found acceptable, the 
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coprocessor then stores the software decryption key 
AK in its permanent memory. At this point the transfer 
is effective so that the coprocessor can use AK to de- 
crypt and run protected software. 

Once the software decryption key AK is stored in 5 
the permanent memory of the coprocessor, the pro- 
tected software can be executed. The plaintext por- 
tion of the protected software is executed by the user 
computer system. The encrypted portion (the protect- 
ed portion) of the software is decrypted upon loading 10 
by the coprocessor. The logical and physical security 
of the coprocessor memory prevents the user from 
having access to plaintext or executable form of the 
protected software. 

On each subsequent use of the protected soft- 15 
ware the software decryption key AK now stored in 
the permanent memory of the coprocessor is used to 
decrypt the encrypted portions thereof. The user can 
make as many "backup" copies of the software as he 
desires; however without access to a logically and 20 
physically secure coprocessor storing the decryption 
key AK, any "backup" copies of the software are un- 
usable since the encrypted portion of the software 
cannot be decrypted. 

Typically, in conjunction with execution of the de- 25 
crypted software by said coprocessor, the authorized 
processor will execute the remaining portions of the 
software, e.g. the originally unencrypted portions. 

The distinct right-to-execute in a preferred em- 
bodiment comprises a decryption key for the encrypt- 30 
ed portions of the software. While the decryption key 
may be distributed along with the software, it is dis- 
tributed in encrypted form. The coprocessor is provid- 
ed, during manufacture, with the key (CSK) required 
to decrypt the software decryption key. Without fur- 35 
ther protection, however, this would authorize any co- 
processor to run any software distributed in accor- 
dance with the preceding description; this would not 
meet the purposes of software authors. Therefore, 
the coprocessor requires further evidence of the 40 
user's right-to- execute; that evidence takes the form 
of an authentic (unused) hardware cartridge. If and 
only if the hardware cartridge meets the challenge of 
the coprocessor will the software decryption key be 
rendered effective. The coprocessor has available to 45 
it (by one of several alternative routes) what is refer- 
red to as token data. This token data can be coupled 
to the coprocessor in encrypted form so that the path 
by which the encrypted token data is made available 
to the coprocessor need not be secure. The token 50 
data is encrypted using the same software decryp- 
tion key. The cartridge stores, in clear text form, the 
token data, and hence the hardware cartridge must 
be physically and logically secure. The coprocessor 
challenge to the hardware cartridge is in the form of 55 
a query, the hardware cartridge responds to the 
query by returning a reply which is a function of both 
the query and the token data. This function does not 



reveal enough about the token data to allow the be- 
havior of an unused token to be reproduced. An ex- 
ample of such a function would be the selection of 
50% of the token content on the basis of the query 
content. As the hardware cartridge generates the re- 
sponse, all the clear text token data which it had stor- 
ed is overwritten or destroyed. As a result of the 
query/response process, the coprocessor receives 
the selected portion or transformation of the clear text 
token data. The process is arranged so that even 
though the communication path between the copro- 
cessor and the hardware cartridge is not secure, 
someone monitoring the transaction (for example 
copying the query and the response) would still have 
insufficient information to simulate the behavior of 
the cartridge. While the coprocessor only receives 
the selected portion or a transformation of the clear 
text token data, since the coprocessor also has avail- 
able to it both the query and the entire clear text token 
data (having decrypted the encrypted token data), 
the coprocessor has available to it all the information 
it needs to determine whether or not the response 
identifies an authentic cartridge. 

The communication path between coprocessor 
and hardware cartridge can either be direct (by cou- 
pling the hardware cartridge to a port in the coproces- 
sor) or be indirect via the host or processor to be au- 
thorized. 

A preferred example of a suitable query is a ran- 
dom number, of specified bit length. The query is in- 
put to the hardware cartridge and is used to select 
among distinctive and exclusive portions of the clear 
text token data as stored in the hardware cartridge. In 
a simple example the query can be binary so that if 
the clear text token data is divided into two portions, 
each bit of the query can be used to select a bit from 
the first or the second portion. A selected bit makes 
up one bit of the response, and simultaneously the se- 
lected and unselected bits are overwritten or other- 
wise erased. In this example then, the bit length of the 
query is equal to half the bit length of the clear text 
token data. Because the communication path be- 
tween the coprocessor and the hardware cartridge is 
unsecured, it is assumed that a pirate will be able to 
copy the query and response. But the pirate is incap- 
able of controlling the query another coprocessor will 
generate and therefore the response which he is 
aware of is insufficient to allow him to simulate the ef- 
fect of an authentic hardware cartridge. 

The software, the associated encrypted decryp- 
tion key EAK and information respecting authorized 
transfer token(s) may be provided on a magnetic me- 
dium (floppy disk or tape). Alternatively, that informa- 
tion can be provided via a communication link (tele- 
phone line, CATV, etc.). The coprocessor which is em- 
ployed in accordance with the method need not be 
permanently attached to or hardwired into the user 
computer system. However, in order to execute the 
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protected software on the computer system, the com- 
puter system must be capable of communicating with 
the coprocessor. If the coprocessor does not yet store 
the software decryption key (AK), the coprocessor 
must also be associated with a transfer token so that 5 
the decryption key AK can be accepted by the copro- 
cessor. The hardware cartridge containing the trans- 
fer token is arranged so that it is capable of authoriz- 
ing an appropriate transfer of a decryption key AK on 
one and only one occasion. This assures that the user 10 
can transfer the software decryption key AK to a sin- 
gle coprocessor. Although the user may freely backup 
the software medium, the protected program can only 
be executed in cooperation with a coprocessor con- 
taining the software decryption key. Because the co- 1 5 
processor is physically and logically secure, the stor- 
ed software decryption key cannot be copied. Be- 
cause the hardware cartridge containing the transfer 
token is both physically and logically secure it cannot 
be copied, and since the act of transferring the soft- 20 
ware encryption key causes the token information 
content to be altered or destroyed, this process can 
only be executed once. 

As described above, the software distribution 
medium included information describing the token. 25 
This information is encrypted to protect it from expos- 
ure to unauthorized sources. However, as will be de- 
scribed below, it is not at all essential for the encrypt- 
ed token description to be contained within or associ- 
ated with the software distribution medium. It is an 30 
advantage if tokens are all unique. For a unique token 
description to be contained on each software distrib- 
ution medium requires in effect that each software 
distribution medium be unique. It would be more ad- 
vantageous if all software distribution media could be 35 
identical as this minimizes manufacturing costs. This 
can be achieved by providing the hardware cartridge 
with the means for storing the encrypted token data. 
All unique information can thus be isolated to the 
hardware cartridge. 40 

As will be described below the transactions to be 
effected are varied in dependence on whether or not 
the encrypted token data is associated with the soft- 
ware distribution medium or the hardware cartridge 
containing the clear text token data. 45 

In either case, the token will be tested by the co- 
processor in such a way that the testing process 
(even though carried out via unsecured conductors) 
does not reveal sufficient token data to successfully 
forge the authorization which the token represents. 50 
To implement this process a "random" number is gen- 
erated by the coprocessor (and retained by it for fu- 
ture use). The "random" number is used to interrogate 
the token which returns to the coprocessor that por- 
tion of the token data which is selected by the "ran- 55 
dom" number. At the cartridge, both the token data 
which is selected (and transferred to the coprocessor) 
as well as token data which is not selected is de- 
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stroyed. In this fashion, even if the response of the 
hardware cartridge is recorded by unauthorized indi- 
viduals, it is useless except in the limited situation 
where the coprocessor generates the identical "ran- 
dom" number or the forger guesses the required re- 
ply. 

For a forger to fool another coprocessor by pre- 
senting that coprocessor with a forged reply to its ran- 
dom number query, either the second query must be 
identical to the first, or the forger must guess the cor- 
rect response to the new query. Both of these can be 
made less likely by using longer queries. By combin- 
ing good random number generation with sufficiently 
long queries to and replies from the token, the job of 
forgery can be made arbitrarily hard. 

The coprocessor accepts the encrypted soft- 
ware key EAK from either the token cartridge or the 
software distribution media (preferred) and decrypts 
it using a coprocessor supervisor key CSK stored in 
the coprocessor at the time of manufacture. 

The coprocessor then accepts the encrypted tok- 
en data (from either the token cartridge or the soft- 
ware distribution medium) and, using the decrypted 
software key AK, decrypts the token data. The copro- 
cessor can then combine the "random" number and 
the clear text token data to determine the "correct" re- 
sponse of the hardware cartridge to its "random" 
number query. The "correct" response calculated by 
the coprocessor can then be compared with the ac- 
tual response of the hardware cartridge, if they com- 
pare favorably, the right of the user to have use of the 
key AK has been established. This use does not in- 
clude the ability to determine the actual content of AK. 

In the event that the encrypted token data is not 
associated with the software distribution medium, it 
can instead be stored in a dedicated register in the 
hardware cartridge. The clear text token data is stor- 
ed in a specialized register set which on reading will 
only provide a portion of the stored information where 
the provided information is selected by the response 
of the read components of the token on the basis of 
the selecting random number. These components 
may further transform the selected information using 
the part of the stored information which was not se- 
lected. Before or after the coprocessor has queried 
the hardware cartridge and received its response (the 
combination of "random number" and clear text token 
data), it can continue interrogating the hardware car- 
tridge so as to read out the encrypted token data. Of 
course, this means that the encrypted form of the tok- 
en data will be available to the user (and any unau- 
thorized individual). But this no more undermines the 
security than having the encrypted token data on the 
software distribution medium where it too is available 
to the user and unauthorized individuals. It should be 
noted that the token contains no cryptographic keys. 
If the coprocessor is considered to be a trusted re- 
ceiver of secret information (AKs) then the token can 



6 



11 



EP 0 266 748 B1 



12 



be likened to a wax seal on an envelope which as- 
sures the receiver that no other receiver has accepted 
that message (an AK). The token, thus gives the soft- 
ware vendor control over the total number of copro- 
cessors that are able to execute their software. It is 5 
this control which is absent at present and allows 
software piracy to exist. 

It should be clear that this system's solution to the 
piracy problem is based on amending both the per- 
sonal computer and the floppy disk by the addition of 10 
a hardware component which compensates for the 
exposures that allow piracy. In the case of the person- 
al computer, that exposure is the availability of the 
complete address and register space of the comput- 
ing system to user scrutiny and command. In the case 1 5 
of the floppy disk (or any other distribution or storage 
media) it is the fact that a functional reproduction of 
the media can be made. It is possible to describe the 
amendments in a manner which makes the applicabil- 
ity of this system to computing systems other than 20 
personal computers clearer. 

The openness of the existing computing system 
is addressed by the addition of a coprocessing sys- 
tem. This system is needed to implement two levels 
of privilege above that of the user of the system. This 25 
is necessary even in the case that the computing sys- 
tem has a CPU which implements privilege. In such 
a system, some user is still responsible for loading the 
operating system and could provide an operating sys- 
tem which supports his access to protected portions 30 
of the vendor's code. Even if the operating system 
were burned in ROM in the CPU, the user would not 
be denied physical access to the protected code. 

The privilege structure dictated by this problem is 
thus a branch on whatever structure is already pres- 35 
ent. This branch contains two levels which are effec- 
tively parallel and separate from the existing struc- 
ture. The two levels of privilege which are added to 
the computer by the coprocessor (or are designed ap- 
propriately into the computing system) have distinct ao 
functions. The lowest of the two levels provides a 
space in which a portion of the vendor's code can be 
executed as a service for the part of the vendor's 
code executing in the open memory of the host com- 
puter. The higher level of privilege in the branch is 45 
used to perform the secure transactions which pre- 
vent proliferation of the rights-to-execute when they 
are installed or used. These transactions are avail- 
able as a service to the lower level of privilege or the 
host. 50 

This architectural extension of present computing 
systems provides support for data processing secur- 
ity functions in general by providing means for the 
trustworthy execution of software. The changed priv- 
ilege structure provides an execution space in which 55 
the software provider has a privilege greater than the 
system user. This privilege level is parallel to, but dis- 
tinct from, the system operator. At this privilege level 



the software provider may execute his product as a 
service to the user without giving access to it as a 
software object. This software is then trustworthy in 
the sense that it cannot be changed or observed by 
the user, but only accessed as a service. The uses of 
such trustworthy execution will be obvious to those 
skilled in the system security area. 

A second level of privilege is provided as part of 
this additional privilege structure. It is the responsi- 
bility of this level of privilege to control the operations 
needed to cause the software product to execute. 
This level of privilege is trustworthy in the sense it will 
only allow execution of code if it has been given the 
right to execute by the software provider. This level of 
privilege has the additional job of isolating applica- 
tions executed at the lower level in the event that mul- 
tiple programs are executed there. This is a classical 
operating system function and is necessary to keep 
code at the lower level trustworthy. 

Accordingly the invention provides a method of 
securing protected software against unauthorized 
use without perturbing existing channels of software 
distribution and, at the same time, not interfering in 
users' creation of unlimited backup copies of protect- 
ed software, said method comprising the steps of: a) 
providing to a user a physically secure coprocessor 
and coupling said coprocessor to a user host comput- 
er to support bidirectional communication therebetw- 
een to create a composite computing system includ- 
ing said host computer and said coprocessor, b) pro- 
viding logical security to said coprocessor by: 1) pro- 
viding a first privilege level including first level secure 
memory and first level operating instructions, se- 
cured against access or variation by said user, for 
executing protected software; c) distributing protect- 
ed software in a form in at which at least a portion is 
inexecutable by said host computer; d) distributing a 
further tangible element distinct from said protected 
software representing a right to execute said protect- 
ed software; e) providing said composite computing 
system access to said protected software and to said 
further tangible element; characterised in that step b) 
further comprises the step of: 2) providing a second 
privilege level including second level secure memory 
and second level operating instructions, secured 
against access or variation by said user or any author 
of protected software, for controlling authorization for 
execution of said protected software by said first priv- 
ilege level; in that, in step c), the protected software 
distributed is executable by said coprocessor but only 
with authorization by said second privilege level; and 
in that the method further comprises the steps of: f) 
verifying authenticity of said further tangible element 
by said coprocessor at said second privilege level; g) 
altering said second level secure memory in a distinc- 
tive fashion to reflect a determination by said second 
privilege level of authenticity of said tangible element; 
and h)executing said protected software so long as 
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said alteration of said second privilege level secure 
memory is detected and denying said request if said 
alteration is not present. 

From the preceding it should be apparent that the 
first privilege level has the function of executing pro- 
tected software as a service to the software vendor 
and to the user, but protecting that software from ac- 
cess by the user. The second privilege level includes 
the key management functions of acquiring a right to 
execute and, once acquired, copying the necessary 
decryption key into the secure memory space (sec- 
ond privilege level) of the coprocessor. As distributed, 
of course, the protected software is in executable by 
the host computer since at least a portion is encrypt- 
ed; the software is executable by the coprocessor 
once it has authorization by the second privilege lev- 
el. The further tangible element is the hardware car- 
tridge storing the transfer token. The manner by 
which the coprocessor verifies the authenticity of the 
transfer token has already been described in detail. 
The alteration to the second level secure memory is 
the writing therein of the software decryption key. 
Whenever execution of the protected software is re- 
quested by the user, access is made, via the copro- 
cessor's second privilege level to the secure memory 
space to determine if the appropriate software de- 
cryption key is present; if present, the coprocessor 
initiates decryption of the protected software and 
storage of that software in the coprocessor's first lev- 
el secure memory space. Subsequently, the second 
privilege level authorizes execution by the first privi- 
lege level. Of course, if the necessary software de- 
cryption key is not present, the user's request to exe- 
cute the software is denied. 

Brief Description of the Drawings 

The invention will now be described in such detail 
to enable those skilled in the art to practice the same 
when taken in conjunction with the attached drawings 
in which like reference characters identify identical 
apparatus and in which: 

Fig. 1 is a block diagram showing major compo- 
nents of the host computer 10 and the coproces- 
sor 15; 

Fig. 2 is a block diagram of the hardware car- 
tridge 20 and its association with a suitable con- 
nector 23, either from the I/O port 1 54 of the co- 
processor 15 or the I/O port 19 of the host 10; 
Fig. 3 illustrates the components of a distributa- 
ble software set in accordance with one embodi- 
ment of the invention; 

Fig. 4 illustrates how the distributable compo- 
nents are created by the software vendor; 
Fig. 5 schematically illustrates the interaction be- 
tween the composite computing system consist- 
ing of the hose 10 and the coprocessor 15, and 
the software distribution package consisting of 



the token cartridge and the distributable soft- 
ware set (Fig. 3) during an acquire right-to- 
execute process; 

Fig. 6 is similar in Fig. 5 except that it illustrates 
5 the interaction of the foregoing components sub- 

sequent to an Acquire Right- To- Execute process, 
that is, during a load, decrypt and run process; 
Fig. 7 is a flow diagram illustrating the services 
executed in the host in accordance with the in- 
to vention; 

Fig. 8 is a flow diagram of the Acquire Right-To- 
Execute process executed in the coprocessor 1 5; 
Fig. 9A illustrates the services executed in the 
host 10 in accordance with a Load Decrypt and 
15 Run process; and 

Fig. 9B illustrates the corresponding services 
executed in the coprocessor in connection with 
the Load Decrypt and Run process. 

20 Detailed Description of Preferred Embodiments 

As described in the above referenced EP-A-0 1 74 
472, the term Personal Computer, or single user sys- 
tem for individual work station, as applied to a class 

25 of small computers can be misleading. These sys- 
tems are more properly termed Single Operator Sys- 
tems. From the point of view of classical operating 
systems, this places the user-operator in a position of 
trust in which he has access to all of the system code 

30 and system facilities. In common Single Operator 
Systems, this exposure of system code and system 
hardware facilities is an opportunity to replicate and 
re-distribute code, which on a classical large comput- 
ing system with separate operators and users, would 

35 be unavailable. The means by which this security is 
achieved on large systems is the implementation of a 
system in which users are given a privileged status 
level which is tested by the system to determine 
whether or not the user may execute certain instruc- 

40 tions or access certain data for reading or modifica- 
tion. 

It is the purpose of the present invention, in com- 
mon with a purpose of the invention of the above ref- 
erenced EP-A-0 174 472 to teach how a system util- 

45 izing privilege may be implemented on Single Oper- 
ator Systems to the advantage of the hardware man- 
ufacture, the software vendor, and the scrupulous 
Single Operator System User. This is referred to as a 
"Shared Higher Level of Privilege System" because it 

50 can be viewed as providing each software vendor 
with a higher privilege level than the user, without giv- 
ing any vendor access to other vendors' privileged in- 
formation. By using this system, a portion of hardware 
and software of the system is hidden in a coprocessor 

55 sub-system which is installed or connected to Single 
Operator System (also referred to as the host or work 
station) so that some portion of the vendor software 
can be made inaccessible to the user except as a ser- 
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vice. In addition the method for transporting software 
either on some magnetic media (floppy disk or tape) 
or via a communication link allows the software ven- 
dor to cryptographically hide some fraction of the 
software from the user In spite of the user being able 5 
to examine it with the resources available to him on 
the system. 

For purpose of this description the host hardware 
or work station is assumed to be IBM Personal Com- 
puter (PC) the operation of which is described in the 10 
IBM Personal Computer technical reference manual, 
1981, the host disk operating system (DOS) is as- 
sumed to be IBM PC DOS. This assumption is for the 
sake of clarity because the operation in DOS services 
of this combination are typical of a class of machines 1 5 
in which this invention is useful. It should be under- 
stood that these DOS and hardware operations are in- 
tended to be representative of all the analogous op- 
erations on this or other possible host systems (in- 
cluding main frame computers) underthis or other op- 20 
erating systems. 

A software copy protection system in accordance 
with the invention employing shared higher level of 
privilege is composed of two parts; the hardware priv- 
ilege support system (a coprocessor) which is instal- 25 
led in or coupled to the work station, and the medium 
(magnetic or otherwise) which is used to transport the 
software from the vendor to the user. As will be de- 
scribed the form in which the software is communicat- 
ed makes it easily copied for backup purposes. In or- 30 
der to obtain a coprocessor's future cooperation in 
executing the software, however, the software must 
at the first use be presented to the coprocessor with 
a token. The token cartridge can effectively be used 
only once and is very resistant to forgery. Copies of 35 
the magnetic media are useless for conveying the 
ability to execute the software package. Use of a tok- 
en gives authorization to the coprocessor to accept a 
decryption key AK so that the software can be exe- 
cuted on the PC (or host) in conjunction with this par- 40 
ticular coprocessor. Other coprocessors which have 
been authorized to use the same key may also exe- 
cute the software. When the token cartridge is used, 
it becomes incapable of conveying subsequent au- 
thorizations. The software vendor is thus provided 45 
with the means for controlling the number of autho- 
rized systems without the need for two way commu- 
nication with the systems. 

The application software must consist of at least 
one file of encrypted program. This part of the appli- so 
cation software is encrypted with a key (AK) provided 
by the software vendor. The software key (AK) is sup- 
plied to the user in encrypted form (EAK), encrypted 
under a key (CSK) known only to the hardware ven- 
dor. The decryption key (CSK) for that e ncrypted soft- 55 
ware key EAK is supplied by the hardware vendor in 
the secure memory of the coprocessor. Encryption of 
an AK to produce an EAK is carried out in such a way 



that the hardware vendor's encryption key (CSK) is 
not available to the software vendor. It is in the best 
interest of the software vendor to encrypt those frac- 
tions of the application software which he considers 
proprietary, as it is the encrypted fraction of the soft- 
ware which will be protected from redistribution by 
the user. 

In the event that the software is to be distributed 
by a magnetic medium (floppy disk or tape) then that 
medium which is ready to be sold or released may 
consist of the following (see Fig. 3): 

1 . An application which consists of at least one 
file of program encrypted with a key AK selected 
by the software vendor. 

2. The decryption key AK needed to render the 
encrypted software executable provided in en- 
crypted form EAK where the encryption is by the 
hardware vendor's (secret) encryption key CSK. 

3. Token data TD which is in encrypted form, ETD 
encrypted with the same software vendor key 
(AK) which is used to encrypt the encrypted por- 
tion of the application. 

As will be described below encryption of the soft- 
ware decryption key is carried out by the use of a co- 
processor wh ich may in all respects be identical to the 
coprocessor which is operated in conjunction with the 
PC. Because of the characteristic of the coprocessor, 
the software vendor who employs this equipment 
does not have access to the information (hardware 
vendor's encryption key CSK) stored therein. 

As will be described below the software may also 
be distributed via a communication link, so long as the 
package of information which is transmitted to a host 
includes the components enumerated above. 

It is a characteristic of the invention that the meth- 
od cannot be defeated by duplication of the software 
and attempting to execute the information enumerat- 
ed above, whether or not it is executed on a host 
which is or is not coupled to a coprocessor unless that 
coprocessor has received authorization to execute 
that software. 

If a pirate wanted to make copies of the enumer- 
ated information which will operate on systems which 
are coupled to the coprocessor he must somehow 
provide for the transfer from the distribution medium 
to the coprocessor permanent storage of the soft- 
ware decryption key. However, as will be described 
below, this transfer requires token data from a use- 
once- hardware-cartridge and, as will be described, 
the hardware cartridge can be arranged so that it is 
arbitrarily difficult to duplicate or forge. In the ab- 
sence of an appropriate token cartridge, the copro- 
cessor will not accept the transfer of the AK which is 
necessary to run the protected program. Thus piracy 
by copying the information that is distributed is inhib- 
ited by the difficulty in duplicating or forging the be- 
havior of an authorizing token cartridge. 

If the pirate wishes to make a copy of the distrib- 
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uted information which will run on systems without the 
coprocessor, then he must first decrypt those parts of 
the application program which have been encrypted. 
Since there are two processors in coprocessor equip- 
ped systems, it is possible that the application may be 5 
written to operate concurrently on two processors, or 
use special facilities on the coprocessor. If so, the ap- 
plication must be drastically modified to be operation- 
al. Piracy by copying a decrypted version of the ap- 
plication is thus inhibited by strength of the encryp- 10 
tion method used to render the application unread- 
able. It is practical to make this a virtually insurmount- 
able task. Even if this were accomplished, the soft- 
ware could still be useless unless it were rewritten to 
run without coprocessor. 1 s 

In order for the copy protection system to be ef- 
fective, it is necessary not only that no copy can be 
made of the distribution information which will convey 
authorization to accept AK into another coprocessor, 
but also that the software must never reside in system 20 
memory in a form which allows the user to make a bi- 
nary image of the system memory with a complete 
working version of the application which could be 
loaded in other systems. 

It is also desirable that the user must be able to 25 
make unlimited quantities of backup copies of the 
software for which the user's coprocessor is autho- 
rized, all of which are useless on unauthorized sys- 
tems. 

These are features of this protection system and 30 
are supported by the coprocessor. The coprocessor 
is itself a computing system. It has it own processor, 
firmware and read only memory (ROM), a real time 
clock and RAM. It could be installed in a personal 
computer as an adapter card set mapped into the 35 
memory and I/O address space, or it could merely be 
coupled to a personal computer via an I/O port. It 
should be noted that it is a feature of the present in- 
vention, as contrasted with the invention described in 
the above referenced EP-A-0 174 472 that the copro- 40 
cessor is portable. The coprocessor communicates 
with the PC in one of two different fash ions. If the co- 
processor is directly installed (such as a card set) in 
a PC, then it can communicate with the PC through a 
region of common memory and through a set of reg- 45 
isters which reside in the port address space of the 
PC. In this version the common memory is part of the 
coprocessor. The coprocessor controls its bus trans- 
ceivers and can cause the common memory to be un- 
available to the PC for read operations. (This architec- 50 
ture is described in the referenced EP-A-0 174 472. 
In the alternative, the coprocessor can communicate 
with the PC through an I/O port. Regardless of the 
manner in which such communication is effected, it is 
necessary that only a portion of the coprocessor 56 
memory be addressable by the PC. It is also neces- 
sary that the portion of the coprocessor memory 
which is not addressable by the PC be physically in- 



accessible to the user. It is this memory in which the 
coprocessor will decrypt and run the encrypted por- 
tion of the application software. 

In addition to the processor, memory (RAM and 
ROM) and port address registers (if any) the copro- 
cessor has physically and logically secure memory 
space which contains ROM and non-volatile memory 
devices (such as battery backed CMOS RAM or EE- 
PROMs). 

The ROM contains the system firmware. It is in 
the form of a monitor whose commands are the ser- 
vices which the PC may request from the coproces- 
sor. A complete set of such services would include as 
a minimum set: 

1. Acquire a Right-to- Execute (ARE). 

2. Load, decrypt, and run application (LDR). 

The non- volatile RAM device is used by the co- 
processor as a secure non-volatile memory in which 
decryption keys AK1, AK2, etc. or initialized applica- 
tions are stored along with all CSKs. 

It should be understood that the coprocessor 
must have at least two levels of privilege so that the 
memory used to store AKs can be properly secured 
from the user. This is needed because the user could 
be a writer-of-sof tware. If the software executed on 
behalf of one author could read the AKs of other au- 
thors, the user-authors could recover other au- 
thors' AKs and decrypt their protected software. 
Management of installation, use of, and access to 
AKs should be understood to be important functions 
of the higher level of privilege to the system. 

All application software decrypted and run on the 
coprocessor is at a lower level of privilege than the 
ROM resident firmware which controls non-volatile 
RAM access and, loading, decrypting, and starting of 
protected software. 

As noted earlier, the coprocessor must be phys- 
ically as well as logically secure. This security is re- 
quired in order to prevent the user from applying logic 
analyzers or other digital control and recording devic- 
es to gain a record of the content of the secure mem- 
ory space and hence the AKs or decrypted software. 
A suitable packaging for the coprocessor is described 
in applicants EP-A-0,268,882, the disclosure of which 
is incorporated by this reference. 

The PC or individual work station is a common 
single bus micro-processor system. The IBM PC is 
typical of this class of machines. Such a system uses 
the bus (which can be an array of transmission lines 
with sockets at intervals) as a communication me- 
dium between logically separate sub-systems. Some 
of the sub-systems may reside on the same packag- 
ing element (in this case a printed circuit board called 
the "System Board") that supports the bus. Sub-sys- 
tems which are necessary to the function of the sys- 
tem or offer expansion of the function of the system 
are handled by attachments to the bus through the 
sockets. It should be noted that the components 
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which constitute a sub-system may be made so that 
parts of the sub-system may reside on different pack- 
aging elements. 

The complement of sub-systems which are 
shown in figure 1 in the region labeled host, as indi- s 
cated at 10, is an example of a common, nearly mini- 
mal, PC. The PC CPU 4 is a single chip micro-proc- 
essor and a group of support chips. The PC CPU 4 is 
supplied with a periodic signal called the clock and 
with connection to the bus by the support chips. The 10 
micro- processor is commonly supplied with more 
support than this, but all support is aimed at executing 
a repeating cycle of fetches of instructions from mem- 
ory, fetches of data from some selected element of 
the sub-systems (such as Random Access Memory), 1 s 
execution of instructions, and when needed, storage 
of resulting data in an selected element of the system. 
The CPU 4 may have support supplied to it called di- 
rect memory access (DMA) which allows the micro- 
processor to be relieved of tasks which involve the 20 
movement of data from one addressable element to 
another. 

The micro-processor controls the type of bus op- 
eration performed (fetch, store, etc.) and the type of 
element selected (RAM, Port Address Register, etc.) 25 
by which of the controls lines in the bus is "asserted" 
(changed to the appropriate potential according to a 
protocol called the bus definition). By these means, 
the micro- processor is able to obtain a collection of in- 
struction (called the program), execute the instruc- 30 
tion on a set of data, and cause the data stored in 
other elements of the system to change as a conse- 
quence of the execution of the instructions. 

The RAM 6 is a sub-system from which data can 
be fetched from and written to by the CPU 4. It is the 35 
sub-system used to store data and instruction which 
are loaded from some other source. If it has meaning- 
ful content, then that content has been written to it by 
the CPU 4. At the time that the computer is powered 
on, the RAM 6 contents are, for practical purposes, ao 
meaningless. 

The ROM 8 is a sub-system from which data can 
only be fetched. It may contain a collection of pro- 
grams which are needed to start useful operation of 
the computer and which are useful for controlling the 45 
remaining sub-systems. 

The remaining sub-systems, terminal control unit 
9, display 11, manual input device 13, disk system 
control unit 15, disk drive 17 and I/O port 19 can be 
characterized as having or supporting both address- 50 
able elements and mechanical, optical or electro- 
magnetic (or other) elements which can affect human 
senses, be affected by human actions, or manipulate 
a magnetic medium to perform read and write opera- 
tions involving creating and sensing the boundary be- 55 
tween magnetic domains on the magnetic medium. 
The contents of some of the adressable elements 
control the actions of the mechanical, optical, and 



electro-magnetic effectors of the sub-system, and 
the contents of other addressable elements are con- 
trolled by the mechanical, optical or electro-magnetic 
elements. Thus, by these means, it is possible for the 
computer system to interact with the user and with 
magnetic and other media. The sub-system which 
provides the elements needed to interact with the 
user is called the terminal control sub-system. The 
common form of sub-system which allow read and 
write operations on magnetic medium are called disk 
control systems. Given these elements it is possible 
to describe in broad outline, the operation of such 
systems. 

At the time of power up, the micro- processor exe- 
cutes an instruction fetch from a fixed location in 
memory. This address is one which is occupied by the 
ROM 8. The instruction in thatlocation is a jump to the 
programs which have the effect of testing and initial- 
izing the system for use. One of the system initializa- 
tion programs causes a program called the Disk Op- 
erating System (DOS) to be read from a disk and exe- 
cuted. This program (the DOS) is able to accept com- 
mands from the user through the use of the terminal 
control system. These commands include causing a 
program chosen by the user to execute on the system 
by naming the file (using the manual input) in which 
the program resides to the DOS program. 

The complement of sub-systems which are 
shown in FIG. 1, as indicated at 15 is an example of 
a minimal coprocessor system. The elements of the 
hardware may be thought of as consisting of two 
parts. One part (at 154) contains addressable ele- 
ments which allow the hardware to communicate with 
the PC so that commands and data may be ex- 
changed (much as between a user and the host sys- 
tem). The other parts contain the coprocessor CPU 
1 50, RAM 151, ROM 1 52 real time clock 1 56 and non- 
volatile RAM 153, not concerned directly with com- 
municating with the PC. 

The non-volatile RAM 153 may be implemented 
as EEPROM or as battery backed CMOS RAM or in 
any other technology which allows erasure of that 
memor/ s contents. 

The combination of properties, non-volatility and 
eraseability are needed so that the software keys 
(AK's) and coprocessor supervisor keys (CSK) can 
be retained between uses of the coprocessor, but can 
be erased in the event that physical intrusion detec- 
tion system 155 detects a tampering attempt; see EP- 
A-0 268 882 for an example of such a system. 

A real time clock 156 is a sub-system which con- 
tains a specialized counter. It is supplied with power 
by a battery, typically the same battery as is used to 
power the nonvolatile memory and the tamper detec- 
tor The battery supplies power to the counter and its 
support chips during the period when the computing 
system is turned off. The counter increments its reg- 
isters in response to clock signals generated by its 
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support chips so that its registers reflect the interval 
of time since the registers were initialized by the co- 
processor manufacturer. Thus, if the registers were 
initialized to the time of day, then their contents would 
approximately track the time of day. The registers of 5 
the real time clock can be read by the CPU 150. 

Figure 1 shows a configuration of the PC and as- 
sociated coprocessor by which software distributed 
in accordance with the invention can be executed. For 
purposes of this description we will assume that the 10 
software is distributed on magnetic media such as a 
floppy disk, although as the description proceeds it 
will become apparent that the software may be dis- 
tributed by any conventional technique. While in ac- 
cordance with the invention described in the refer- 15 
enced EP-A-0 174 472 the Support Hardware com- 
municated with the host through its internal bus, it is 
a feature of the present invention that the coproces- 
sor can be coupled to the PC through a communica- 
tion port, so that the coprocessor can be conveniently 20 
portable. We will describe operation of the system us- 
ing this configuration although it should be apparent 
that the present invention can also be employed when 
the coprocessor communicates to the PC through an 
internal bus. 25 

The coprocessor 15 has some features in com- 
mon with the Support Hardware of the referenced EP- 
A-0- 174 472. More particularly, the coprocessor pro- 
vides each software vendor with an instance of a 
higher privilege level than the user but at the same 30 
time does not give any software vendor access to 
other vendors' privileged information. All application 
software decrypted and run on the coprocessor is at 
the lower of the two privilege levels; the higher privi- 
lege level, implemented in the ROM resident, firm- 35 
ware, controls access to the non-volatile RAM 153, 
loading, decrypting and running operations. This 
structure in the coprocessor prevents a software 
vendor from writing a monitor which would run on the 
coprocessor to access the firmware and non-volatile 40 
memory (including the decryption keys) and make 
that information available to the host 10. 

Accordingly, the coprocessor 15 has a first or 
lower privilege level which has access to the RAM 
151; as already described, the RAM 151 is secured 45 
from the user and/or the host 10. The first privilege 
level includes first level operating instructions for 
executing protected software. The coprocessor 15, 
however, also has defined a second privilege level in- 
cluding a second level secure memory and second 50 
level operating instructions. The second level secure 
memory is represented by the non-volatile RAM 153 
and the second level operating instructions are de- 
fined in the ROM 152. The second privilege level is 
secured both against the user and any software au- 55 
thor. It is the second privilege level of the coprocessor 
1 5 which is involved in acquisition of rights to execute 
and therefore controls the procedures antecedent 



thereto. The same second privilege level also re- 
sponds to user requests for execution of protected 
software, provides for the loading and decryption of 
protected software and initiating the first privilege 
level into operation for execution of the protected 
software, but only in the event that the second privi- 
lege level determines that such execution is autho- 
rized. 

There are, in accordance with the present inven- 
tion, two modes of operating on or with protected 
software, a first mode called Acquire Right-to- 
Execute (ARE) is required to authorize the coproces- 
sor to execute the protected application. Each copro- 
cessor may be authorized to execute many software 
applications by performing the ARE transaction for 
each application. Thereafter, when the apparatus 
executes a software package for which it is autho- 
rized, it operates in a Load, Decrypt and Run (LDR) 
mode. 

Figure 3 describes a software configuration 
which is employed in accordance with the present in- 
vention. As shown in Fig. 3 the three files may be dis- 
tributed as unit (either on a magnetic medium or via 
a communication link). Af irstf ile is an encrypted soft- 
ware decryption key EAK. The second file is the soft- 
ware which includes both plain text software (PART 
1) and protected or encrypted software (PART 2) 
(EAK (Software, Part 2)). The last file is encrypted 
token data EAK(TOKEN DATA). While the encrypted 
software no encrypted token data are encrypted us- 
ing a common key (AK), such that each of them can 
be decrypted using the decryption key (AK), the soft- 
ware decryption key is encrypted with a different key 
(CSK); the hardware vendor's key which, as will be 
described, can be maintained secret from the soft- 
ware vendor. While in accordance with the invention 
described in the referenced EP-A-0 174 472, a key 
pair using a "public key" cryptographic system must 
be used to encrypt and decrypt the software key, it 
is a feature of this system that any adequately secure 
cryptographic system may be used including DES or 
other "symmetric" key systems in which the same key 
is used for encryption and decryption. 

For purposes of this description we will assume 
that the three files of figure 3 are contained in floppy 
disk which is loaded in the disk drive 17. In order to 
initialize the coprocessor, a token cartridge 20 is cou- 
pled to the coprocessor 15 or to the host PC 10. The 
cartridge 20 includes token data stored in a memory 
device which has unique characteristics as will be de- 
scribed below. At this point it suffices to note that the 
cartridge 20 is arranged so that it can be used on a 
single occasion; the act of employing the cartridge 20 
alters it such that it is no longer usable for its intended 
purpose. 

In order to employ the (protected) software the 
coprocessor 1 5 must be provided with the decryption 
key (AK) which is needed to render the encrypted por- 
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tion of the application executable. This key will be 
transferred to the software owners coprocessor 1 5 in 
such a way that the transfer mechanism cannot be re- 
used or reproduced. This is accomplished by requir- 
ing the presence of an unused token cartridge to ef- 5 
fectively transfer the decryption key into the nonvo- 
latile memory of the coprocessor 1 5. "Unused" in this 
context means only that the content of the token car- 
tridge supplied by the software author has not been 
read by any means prior to this occasion. As noted the w 
token is difficult to forge for reasons which are dis- 
cussed later and is effectively erased in the transfer 
transaction. The token has information content which 
is identifiable to the coprocessor 15 either because it 
is enumerated in an encrypted file associated with 15 
the program (or alternatively provided by another 
source, as described below). The enumeration evi- 
dences the feet that this has been provided by the 
software author. It is authenticated to the coproces- 
sor 15 by the fact that the information is encrypted 20 
with the same key (AK) which the software vendor 
has used to encrypt the protected portion of the ap- 
plication. 

The cartridge 20, storing the transfer token is 
coupled to the I/O device 1 54 of the coprocessor (not 25 
illustrated) or the I/O device 19 of the PC (as illustrat- 
ed) via a connector provided for that purpose. Since 
the connector to the cartridge 20 is exposed, and can 
therefore be monitored by the user, the transaction 
which uses the connector must be difficult to forge 30 
given that some of the data will be exposed. To have 
this property, each transaction should be effectively 
unique and verifiable by the coprocessor. 

The cartridge 20 is both physically and logically 
secure. Physical security may be provided in a nunv 35 
ber of fashions, one of those fashions is described in 
the applicants EP-A-0 268 882. A preferable method 
of physical security is to implement the circuitry of the 
token as a single integrated circuit chip. The cartridge 
20 includes memory which behaves in such a fashion 40 
which allows verification of no-prior-use as well as 
verification of its authenticity. Both verifications are 
needed by the coprocessor before the descryption 
key AK will be accepted for future use. As will be de- 
scribed below the cartridge 20 may be manufactured 45 
by a third party source so long as its connector and 
protocol are standardized. Its information content 
must be determined and loaded by the software au- 
thor or the author's representative. Data is transfer- 
red from the cartridge to the coprocessor using a 50 
query/response protocol. The query is a random num- 
ber, and it in combination with the token data deter- 
mines the token response. The accessible informa- 
tion passing on the unsecured path between copro- 
cessor 15 and cartridge 20 is the "random number" 55 
and the response of the cartridge, neither of which re- 
veals the token data. The coprocessor has access to 
a copy of the token data (for example by decrypting 



the encrypted token data from the software distribu- 
tion media). Thus the coprocessor can independently 
determine the ■correct" response, and can compare 
the actual response from the cartridge 20 with its 
own, independently determined "correct" response. 
Thus only the random query and the actual response 
are exposed during the transaction. The complete 
token information needed to combine with the query 
to obtain the response is not revealed. At the same 
time as the cartridge 20 produces its response, it also 
alters its contents so the cartridge cannot be reused. 
This is accomplished by providing a region of memory 
in cartridge 20 which does not behave as if it were a 
normaJ memory under read operation. (A block dia- 
gram with suitable architecture for the cartridge 20 is 
shown in figure 2). Briefly, the cartridge 20 includes 
at least two memory segments, both of which can be 
written to as if they were conventional serial input 
shift registers. When a read is performed, however, 
the access properties of the regions changes. During 
reads both memory segments are enabled and pro- 
duce data at an output as would a normal serial output 
shift register. Both the outputs are sent to a multiplex- 
er. The multiplexer selects which of the two (or more) 
segment's data to route to the connector (and thus to 
the coprocessor) by the state of a control line which 
is contained within the connector, and which is driven 
by the coprocessor with the "random number". When 
the memory region of the cartridge is read out, the 
contents in both segments are erased. This ensures 
that a pirate observing the transaction between the 
coprocessor and the token cartridge can only obtain 
a portion of the information content of the cartridge. 
This portion of the token information is sufficient to 
verify to the coprocessor that it is a valid token which 
can authorize the coprocessor to use the software 
package but it is far from sufficient to allow a pirate 
to reconstruct its original content in order to fool the 
coprocessor into accepting a key which is not right- 
fully owned. 

In an embodiment of the cartridge 20 which was 
described above, two shift registers are employed, so 
that during a read, the selected 50% of the memory 
contents are exposed. In alternative versions larger 
memory segments, or larger granularity of selection 
than a bit, or using addressable stored data to re- 
spond to queries are suggested techniques. These 
variations offer trade-offs to the system designer 
concerned with cost versus security. 

During this read operation a portion of the con- 
tents of the cartridge 20 is transferred to the copro- 
cessor. The portions which are selected are deter- 
mined by a "random" number generated by the copro- 
cessor. Both the "random" number as well as the re- 
sponse from the cartridge 20 are then stored in the 
coprocessor. This information can then be compared 
with the token data (file 3-figure 3) which is also 
transferred to the coprocessor from the software dis- 
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tribution medium. Failure of the token data to corre- 
spond to the expected token data is taken as proof of 
forgery of the token cartridge and results in rejection 
by the coprocessor of the decryption key for future 
use, and of course only if the decryption key is ac- 5 
cepted for future use can the protected software be 
executed. 

Figure 2 is a block diagram of one embodiment of 
cartridge 20. In this embodiment the token device is 
implemented as a single silicon CMOS integrated cir- 10 
cuit chip 25 for cost and physical security reasons. 
This chip is appropriately packaged so that the data 
storage elements 120, 220 are continuously powered 
by a battery 26. CMOS integrated circuits can be built 
with static power requirements so small that the data 1 s 
stored in these registers, if not read out, can be ex- 
pected to be preserved for a period almost equal to 
the shelf life of the battery. In the case that the data 
is read, as will be described, the other components 
needed to affect reading are supplied with power from 20 
an external source through the external power and 
ground lines 27. As shown in figure 2 the cartridge 20 
is coupled to the coprocessor or the host PC via con- 
nector 23 having Clock, Selection, Data Input, Data 
Output, External Power and External Ground lines. 25 
The cartridge 20 contains two memory segments in 
the form of Serial In, Serial Out, Shift Left, Shift Reg- 
isters 120, 220, a first segment including cells 121- 
12n and a second segment including cells 221-22n. 
Shift registers of this kind have the property that the 30 
state of the bit stored in their left-most cells (121, 221) 
is reflected in the state of their output lines (D1 , D2). 
They have the additional properties that when the fall- 
ing edge of a clock pulse is presented at their dock 
lines (C1.C2) the state of each cell is changed to that 35 
of the cell to its immediate right so that the pattern of 
bits in the register is shifted to the left In the case of 
the right-most cells (12n, 22n) the falling edge of the 
clock pulse causes these cells to assume the state of 
the data input lines (D3, D4). The cells can be filled 40 
with data by supplying a data bit at each of the two 
data input lines and then supplying a clock pulse. If 
this procedure is repeated for n clock pulses, then all 
n bits of the registers will be filled. An encrypted (un- 
der AK) copy of these bits could then be made and 45 
stored on a floppy disk to supply the encrypted de- 
scription of the token data. This procedure is followed 
by a software author to prepare the authorization to 
a coprocessor to accept an AK. 

When a read operation is performed, each bit of so 
the coprocessor generated random number is placed 
consecutively on the select line. Each setting of the 
select line 21 is followed by a clock pulse. Both shift 
registers will shift left on each clock pulse. Data from 
the first shift register is placed on the line D1 and from 55 
the second shift register on the line D2; both of which 
are inputs to a multiplexer 22 which is in turn control- 
led by the select line 21 from the coprocessor or host 



PC. The select line 21 determines which of the two 
signals D1 or D2 are coupled through the latch 24 to 
the output DATA. The latch is used to prevent a pirate 
from obtaining the token data by changing the select 
twice for each clock pulse. The consequence of this 
arrangement is that for each bit which is presented at 
the data out, two bits have been shifted out of the reg- 
isters, and two bits, which are useless for authoriza- 
tion, have been shifted in. 

Accordingly, and assuming that the entire mem- 
ory contents of the cartridge 20 were read out, one 
observing the input to the select line 21 and DATA out- 
put, would only observe, at most, 50% of the contents 
of the cartridge 20. The coprocessor knows from the 
Encrypted token information exactly what bits should 
have appeared in that 50% so it has sufficient infor- 
mation to confirm the validity of that authorization, but 
a pirate lacking the destroyed 50% will not be able to 
forge an authorization. 

When the coprocessor 15 is requested to acquire 
an AK (ARE), a process (see Fig. 5) is initiated. This 
begins when the encrypted software decryption key 
(file 1) and encrypted token data (file 3) are read into 
the RAM 151 or temporary memory 15T. In addition, 
a "random" number (3) is generated by the coproces- 
sor and used in performing a read operation on the 
cartridge 20 as previoulsy described. The "random" 
number is used to select which bits of which memory 
segments will be effective to pass the multiplexer 22. 
The coprocessor 15 stores the "random" number in 
RAM 151 along with the resulting DATA (4) from the 
cartridge 20. 

It should be understood by those skilled in the art 
that there are a very large number of variations on the 
design of the token cartridge. All have the properties 
that the data read from the cartridge is transformed 
as a function of both the query bits and the token data 
content and that the resulting reply from the token is 
predictable if the complete content of the token is 
known. 

The coprocessor decrypts the software decryp- 
tion key Ecsk(AK) and the resulting software decryp- 
tion key (AK) is used to decrypt the token data to pro- 
duce clear text token data. In the case that there are 
multiple CSKs, the encrypted software key could be 
supplied with a reference to the correct CSK in a 
header. Such headers could provide an index to the 
correct CSK in plain text or a recognition flag which 
decrypts to an expected pattern only if the correct 
CSK is used. Many other methods are possible. Hav- 
ing decrypted EAK with the correct CSK, the copro- 
cessor can then combine the stored "random" number 
or query with the dear text token data and indepen- 
dently determine the "correct" response. The actual 
response (the DATA received from the cartridge 20) 
can then be compared to the "correct" response. If the 
two quantities compare favorably that is taken as an 
indication that the cartridge 20 authorizes the copro- 
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cessor to store AK (5) in nonvolatile RAM or perma- 
nent memory 15P for future use. The user can now 
successfully request that the coprocessor execute 
the software protected by the newly acquired AK. It 
should be noted that the key AK may be re-encrypted 5 
by the processor prior to storage. This step of re-en- 
cryption could provide improved protection of the 
stored key or could, if used correctly, support storage 
of the key outside the coprocessor. 

On the other hand, if the "correct" and actual re- 10 
sponse of the cartridge do not compare favorably, the 
software decryption key (AK) is discarded and the co- 
processor is unable to properly execute the encrypt- 
ed software wherefore the application program will 
not run properly. 15 

It should also be apparent that this transaction 
destroys the content of the cartridge 20 (see Fig. 6) 
so that it cannot be reused to authorize any other co- 
processor to run the application, or any other applica- 
tion program. 20 

The enormous number of possible selections of 
the contents of the different segments of the car- 
tridge that can be made by the coprocessor and the 
amount of information in which the pirate must recon- 
struct by trial and error are the barriers to the pirate's 25 
successful reconstruction of the cartridge 20. The 
probability of successful forgery (P (Forgery)) is a 
function of the probability that the coprocessor will 
ask for the same selection at any given bit of the re- 
quest (P (same)), the probability that the pirate will 30 
guess the "lost" data of an observed transaction cor- 
rectly (P (guess)), and the number of bits requested 
by the coprocessor in the validation transactions 
(Numbits). P(forgery) = (P(same) + (1- P(same)) (P- 
(guess))) to the power Numbits. If P(same) = 0.5 and 35 
P(guess) = 0.5 and Numbits = 128 as could easily be 
achieved in practice with a small integrated chip, then 
P(forgery) is approximately ten to the -16th power. If 
the rate of which a pirate would test his guesses is 
once per second, then even such a small cartridge ao 
would force a search lasting, on an average, more 
than two hundred million years. The coprocessor is, 
thus, able to determine reliably whether or not the car- 
tridge it is reading was supplied by the software ven- 
dor to validate ownership or is a forgery, without ex- 45 
posing the information needed to create a successful 
forgery. The coprocessor will only store a decryption 
key (AK) for later use after the cartridge has been 
verified. 

Figure 4 shows how the software vendor can con- so 
struct a distributable software product, to be distrib- 
uted on a magnetic medium or via communication 
link. The software vendor begins with three compo- 
nents, 

A. The application software, 55 

B. A software decryption key AK (known to the 
software vendor only), and 

C. Token data (a random number, known to the 



software vendor only). 

The software vendor, in a first function (F1).uses 
his own (secret) encryption key AK to encrypt the tok- 
en data as well as critical parts (part 2) of the appli- 
cation software. The result of this encryption process 
becomes the encrypted token data [E^TOKEN 
DATA)] which will be distributed and the encrypted 
application software ^^(Software)]. 

The noncritical parts of the application software 
(part 1)forms another component of the distributable 
software product. 

Finally, the software decryption key (AK) is en- 
crypted in a f unction F2, using the hardware vendor 
encryption CSK. The result of this process is the en- 
crypted key [Ecsk(AK)] forms the last component of 
the distributable software product 

Figure 4 shows that function F2 is enclosed in a 
double rectangle to indicate that the encryption proc- 
ess takes place in the software vendor's coprocessor 
so that the hardware vendor's encryption key (which 
is contained in the coprocessor) is unknown to the 
software vendor. 

In this fashion, the software vendor is prevented 
from acquiring knowledge of the hardware vendor's 
encryption keys. Software vendors can choose which 
hardware vendor's coprocessors they are willing to 
allow their keys to be installed on by preparing En- 
crypted Software Keys (EAKs) only with the copro- 
cessors provided by trusted manufacturers. It is 
clearly in the best interests of the trusted hardware 
manufacturers not to destroy the effectiveness of 
their own product by revealing their own CSKs or us- 
ing their own CSKs to reveal the software vendor's 
AKs. Accordingly, no "secret" data need be shared 
between the software and hardware vendor. 

Comparing Figs. 5 and 6 reveals that, subse- 
quent to the ARE process, the token cartridge 20 has 
had the token data erased, removed or overwritten so 
that it is no longer accessible. Fig. 6 shows the regis- 
ters in the cartridge 20 as "empty". These registers 
are "empty" in the sense that the clear text token data 
which had resided there prior to the ARE process has 
been replaced by the data provided on the connector 
23 (see Fig. 2) over the lines D3 and D4. This data is 
meaningless to the validation process, and thus in 
terms of information content the registers in the token 
cartridge 20 are indeed "empty". Upon successful 
completion of the ARE process, the software decryp- 
tion key AK, received by the coprocessor 15 in en- 
crypted form Ecs K (AK) has been decrypted, and in re- 
sponse to successful completion of the ARE, AK has 
been transferred (5) to the permanent memory 15P of 
the coprocessor 15. Fig. 6 also illustrates operation 
of the coprocessor 15 during the LDR. During this 
process, the software decryption key AK (5) is copied 
to the temporary memory 1 5T. The plain text software 
(file 2) is transferred to the host 1 0, where it is execu- 
table inasmuch as it is in plain text form. The encrypt- 
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ed software (8) is transferred to the coprocessor 15 
and resides in the temporary memory 1 5T. At that lo- 
cation, and employing the software decryption key 
AK, the encrypted software is decrypted (9) so that 
it is executable by the coprocessor 15. 5 

Because the coprocessor 1 5 is secure, the clear 
text protected software, although it resides in the 
memory of the coprocessor 15, is unavailable to the 
user or anyone else. The software is, however, 
executable by the coprocessor 15, and the results of 10 
that execution can be communicated to the host 10. 
As a result, the composite computing system consist- 
ing of the host 10 and the coprocessor 15 cooperates 
in executing the softwared application package, the 
host or PC 1 0 executes the plain text portion, and the 15 
coprocessor 15 executes the protected portion, al- 
though if desired, the entire application could be pro- 
tected and run solely on the coprocessor 15. 

Figs. 3-6 illustrate an embodiment and applica- 
tion of the invention wherein the encrypted token data 20 
is provided to the user on the same medium which 
supports the application software, and while that me- 
dium could be magnetic, it is also within the contem- 
plation of the invention that it could consist of a com- 
munication link. 25 

Associating the encrypted token data with the 
software necessitates that to at least some extent the 
software distribution medium is unique or relatively 
unique (by the presence of the encrypted token data). 
As mentioned above, however, there are advantages 30 
if the distributable software medium can be generic 
and in that embodiment of the invention the encrypt- 
ed token data does not appear on the software dis- 
tribution medium (or is not associated when transmit- 
ted over a communication link with the application 35 
software). It is still essential, however, for the en- 
crypted token data to be communicated to the copro- 
cessor 15, because that information is essential to ac- 
quiring the right to execute. In this alternative embodi- 
ment of the invention, the hardware cartridge 20 is 40 
modified so that it includes at least a register dedicat- 
ed to storing encrypted token data. The coprocessor 
15, in addition to generating the challenge or query 
which has been described above, also generates a 
unique command and sufficient clocking pulses to 45 
transfer the encrypted token data, in toto, into the co- 
processor 15. In this alternative embodiment of the in- 
vention then, the hardware cartridge 20 stores not 
only clear text token data (in the shift registers 120 
and 220) but also stores encrypted token data in a 50 
third register (not shown in Fig. 2). 

Fig. 7 is a flow diagram showing the functions 
executed in the host 10 in accordance with the inven- 
tion; the services shown in Fig. 7 are those specific 
to the invention, other conventional services are not 55 
illustrated. As shown in Fig. 7, an initial determination, 
H1, determines whether or not the ARE process is re- 
quested. On first running, any particular application 



package in accordance with the invention, this re- 
quest would be present Accordingly, function H2 is 
then requested to send the ARE request to the copro- 
cessor 1 5. A loop is then entered consisting of H3 and 
H4 in which the host 10 services coprocessor re- 
quests until the coprocessor 15 indicates that it has 
completed the ARE process. On completion of the 
loop, processing loops back to function H1. 

Subsequent to performing steps H1-H4, or at any 
time the LDR process is to be executed (on the sec- 
ond and any subsequent execution of the application 
software in accordance with the invention), function 
H1 directs processing to function H5. H5 determines 
if the LDR process is requested, rf LDR is not request- 
ed, then function H6 determines if existing these ser- 
vices are requested; if not processing loops back to 
block H1. If an exit is requested then the processing 
shown in Fig. 7 terminates (END). 

On the other hand, if at function H5 an LDR re- 
quest was recognized, then function H7 is performed 
to send the LDR request to the coprocessor 15. 

A loop is then entered consisting of functions H8 
and H9 which is entirely similar to the loop H3-H4. 
When the coprocessor H9 indicates that LDR proc- 
essing has been completed, then function H10 is per- 
formed to notify the corresponding program (for ex- 
ample the application program) in the host 10 that the 
LDR processing is completed. 

When function H2 is performed, the coprocessor 
15 is stimulated to execute its portion of the Acquire 
Right-To-Execute process. Those functions are 
shown in Fig. 8. Of the two privilege levels referred to 
previously, the ARE process is at the higher privilege 
level since its function is to protect dissemination of 
rights to execute for the software vendor's protection. 

As shown in Fig. 8, function C1 requests the en- 
crypted software decryption key from the host 10. 
The host 10 has access to this information from the 
software distribution medium (or communication link 
in the event the software is distributed in that form). 
Function C2 decrypts the encrypted software de- 
cryption key since it has access to CSK. CSK was in- 
stalled by the manufacturer of the coprocessor 15 in 
the permanent 15P, at the time of manufacture. As 
has been indicated, there may be more than a single 
CSK, in that event the encrypted software decryption 
key file would contain a header, index or address to 
identify the appropriate CSK. Function C3 then re- 
quests the encrypted token data from the host. In the 
event the encrypted token data is associated on the 
same software distribution medium as is the applica- 
tion, the host 10 has access to it. Alternatively, the en- 
crypted token data could be stored in the hardware 
cartridge 20; but as already described the host 10 
may have access to the hardware cartridge 20, and 
if it does not, the coprocessor 15 has direct access to 
the hardware cartridge 20. 

Function C4 decrypts the encrypted token data 
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using the already available software decryption key. 
The decrypted token data is then retained in the tem- 
porary memory 15T. 

Function C5 then generates the random number 
which forms the token query. Function C6 combines 
the random number and the token data to si mulate the 
token response and generates the computed re- 
sponse which is likewise retained in the temporary 
memory 15T. 

Function C7 then requests the host to query the 
hardware cartridge 20 with the random number (the 
token query). Of course, if the coprocessor 15 has di- 
rect access to the hardware cartridge 20, this function 
is implemented directly rather than indirectly through 
the host 10. Function C8 then requests the host to 
supply the token response, which is also stored in the 
temporary memory 15T. Function C9 then compares 
the actual response with the computed or expected 
response. Function C10 is a branch based on the 
comparison of function C9. If the computed and ac- 
tual response of the token compare favorably (typical- 
ly they would be equivalent) then that is taken as evi- 
dence or an authentic token. Function C1 3 thereafter 
moves the software decryption key into permanent 
storage (5). Function C14 then passes a message 
through the host 10 to inform the user that a success- 
ful ARE process has been completed and provides in- 
formation to the host 10 to identify the location of the 
software decryption key corresponding to this appli- 
cation. Thereafter, the ARE process terminates. 

On the other hand, if the comparison of the actual 
and computed response of the token was unsuccess- 
ful (for example the responses were unequal) then 
rather than executing functions C13 and C14, func- 
tion C 11 is executed to pass onto the user information 
that the Right-To- Execute was not acquired. It should 
be noted that in this event, although the software de- 
cryption key is available in the temporary memory 
15T, it is not transferred into the permanent memory 
15P. Accordingly, the software decryption key is un- 
usable and the application package will not execute. 

Fig. 9A illustrates the functions performed in the 
host during a typical LDR process. Initiating the LDR 
process is function H11 which starts the application 
program. On determining that the program is protect- 
ed, function H12 is performed requesting an LDR or- 
der to DOS with the information to determine the lo- 
cation of AK, e.g., the location in the permanent mem- 
ory of the coprocessor 15 at which the necessary 
software decryption key is located. This information 
had been provided to the host and stored with the ap- 
plication program via function C14 at the successful 
conclusion of the preceding ARE process. 

Function H13 then is merely a delay waiting for 
notification from the DOS service (see Fig. 7). On 
that notification (H10 - Fig. 7), function H14 is per- 
formed to execute the application using code execut- 
ing in the coprocessor 15 as needed. In order to see 



how the protected software is executed in the copro- 
cessor, reference is made to Fig. 9B. 

As shown in Fig. 9B, when the coprocessor 15 re- 
ceives an LDR request, function C15 is performed to 

5 initiate the functions shown in Fig, 9B. The LDR re- 
quest is initiated at function H7 (see Fig. 7). Function 
C1 6 requests the host to provide information to locate 
AK. That request is passed through the DOS service 
(Fig. 7) which responds with the information provided 

10 by function H8. With the index information, function 
C17 obtains a copy of the software decryption key 
from the permanent storage and loads it into the tem- 
porary memory 15Tof the coprocessor 15. Function 
C18 then requests the protected software from the 

15 host. The protected software, in encrypted form, is re- 
tained in the temporary memory and decrypted, at 
function C19, using the software decryption key ob- 
tained at function C17. The result of function C19 is 
the clear text version of the protected software; this 

20 is retained in the temporary memory 1 5Tof the copro- 
cessor 15. The protection afforded by the logical and 
physical security of the coprocessor 15 prevents dk 
vulgence of the clear text portion of the protected 
software to the user or anyone else. Function C20 

25 then notifies the host that the LDR process has been 
completed. Function C21 then executes the decrypt- 
ed software. Functions C17-C19 are also considered 
to represent the higher of the two privilege levels 
since they deal with use of the right to execute, AK. 

30 Function C21 , on the other hand, is an example of the 
lower of the two privilege levels. It should be apparent 
to those skilled in the art that functions H14 and C21 
can cooperate using a variety of techniques so that 
the net result is complete execution of the application 

35 software. It is within the scope of the invention that all 
of the application software is protected. During exe- 
cution of the protected software by the coprocessor 
1 5, only the results of that execution are provided to 
the host 10. It should be apparent that the results of 

40 the execution, which is available to the user, is inade- 
quate as a basis on which to reconstruct clear text or 
the protected software. 

The invention then meets the objects previously 
stated. More particularly, the software distribution 

45 medium can be freely copied or backed up, however, 
it will not execute except on composite systems in- 
cluding a coprocessor such as the coprocessor 15. 
Even then, it will only execute on a composite system 
in which the coprocessor 15 has available to it the 

50 necessary software decryption key. Furthermore, in 
order for the coprocessor 15 to obtain access to the 
software decryption key, and retain that information 
in permanent memory, an authentic cartridge 20 is 
necessary; the cartridge 20 is arranged so that it is 

55 difficult to forge or simulate and is usable only on one 
occasion. The necessary consequence is that a suit- 
able hardware cartridge 20 can authorize one and 
only one coprocessor 15. While only a single copro- 
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cessor 15 will be authorized, that coprocessor 15 is 
in essence portable so that it could be used with any 
suitable host 10 to run the protected software. Thus 
the software vendor achieves the desirable result of 
separating the protected application software from 
the right to execute it His customer, the user, can 
make as many copies of the protected software as he 
desires but can only execute it, at ony one time, on a 
single composite computing system. 

CONDITIONING RIGHTS TO EXECUTE 

The software asset protection mechanism, as 
briefly described above, installs an unconditioned 
right to execute in the coprocessor 15. However, it is 
one of the features of the invention that the right to 
execute can be conditioned, and examples of condi- 
tions are terminal dates and times, or numbers of exe- 
cutions. Figs. 10 A-C illustrate the case where the 
protected portion of the application file includes a cri- 
terion for execution, e.g., if the terminal date and/or 
time is later than the present date then execution is 
allowed. On presentation of a distribution set as 
shown in Fig. 10A to the combined processing system 
of the host 1 0 and the coprocessor 1 5, the installation 
of the right to execute proceeds exactly as was de- 
scribed above. The coprocessor 15, via the agency of 
the host 10, verifies (and destroys) the token 20 by 
comparing its plain text contents (T^ with a decrypted 
version of the file E^f^) read from the disk 46. On 
verifying the authenticity and the previously unused 
nature of the token 20, the coprocessor 15 stores the 
software decryption key AK in the permanent mem- 
ory 15P. The conditions of execution can be stored in 
the same file as the AK and can be installed at the 
same time as AK. In the case shown in Fig. 10A, the 
coprocessor 15 stores the datum which can be inter- 
preted as a terminal date and/or time. This interpre- 
tation will be performed by the protected part of the 
application on any occasion of its use. The terminal 
date storage is associated with the software decryp- 
tion key AK, as shown in Fig. 10B. More particularly, 
Fig. 10B is entirely identical to Fig. 1 0A except that it 
shows the software decryption key AK, and the ter- 
minal date and/or time, stored in the coprocessor 1 5's 
permanent memory as well as indicating that the tok- 
en 20 has been depleted. Thereafter, each time the 
protected application is run on the coprocessor 15, 
prior to authorizing execution, the application uses 
the criterion stated in the encrypted application file 
that the current date and/or time not be later than the 
terminal date and/or time and only authorizes execu- 
tion in the event the criterion is met The current date 
and/or time is supplied on demand by the coproces- 
sor 15 to the executing application. 

Fig. 10C is similar to Fig. 1 0B except that the con- 
ditions stated in the encrypted application key file 
gives the remaining number of authorized executions. 



On installation of the right to execute, the software 
decryption key AK is associated with a count C; each 
time execution of the application is requested, the 
contents of the count C is tested against the criterion 

5 that the number C of authorized executions remaining 
is greater than zero. The count C is then decrement- 
ed. Only so long as C is greater than zero will execu- 
tion be authorized. 

It may be advisable, regardless of whether or not 

10 the condition is a terminal date and or time, or a num- 
ber of executions, to provide the coprocessor 15 with 
instructions to delete the associated software de- 
cryption key AK, once the initial conditions are no lon- 
ger met Thus, the software decryption key AK is au- 

15 tomatically removed from the permanent memory 
and thus the right to execute is deleted. Further de- 
tails of conditioning rights to execute are described in 
the EP-A-0,268,139 which is incorporated herein by 
reference. 

20 

Claims 

1. A method of securing protected software (46) 
25 against unauthorized use without perturbing ex- 

isting channels of software distribution and, at 
the same time, not interfering in users' creation 
of unlimited backup copies of protected software, 
said method comprising the steps of: 
30 a) providing to a user a physically secure co- 

processor (1 5) and coupling said coprocessor 
to a user host computer (10) to support bidir- 
ectional communication therebetween to cre- 
ate a composite computing system including 
35 said host computer and said coprocessor; 

b) providing logical security to said coproces- 
sor by: 

1) providing a first privilege level in- 
cluding first level secure memory (151) and 
40 first level operating instructions (152), se- 

cured against access or variation by said user, 
for executing protected software; 

c) distributing protected software (46) in a 
form in which at least a portion is inexecutable 

45 by said host computer, 

d) distributing a further tangible element (20) 
distinct from said protected software repre- 
senting a right to execute said protected soft- 
ware; 

50 e) providing said composite computing sys- 

tem access to said protected software and to 
said further tangible element; 
characterised in that: 

step b) further comprises the step of: 
55 2) providing a second privilege lev- 

el including second level secure memory (153) 
and second level operating instructions (152), 
secured against access or variation by said user 
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or any author of protected software, for control- 
ling authorization for execution of said protected 
software by said first privilege level; 

in that, in step c), the protected software 
distributed is executable by said coprocessor but 
only with authorization by said second privilege 
level; 

and in that the method further comprises the 
steps of: 

f) verifying authenticity of said further tangi- 
ble element by said coprocessor at said sec- 
ond privilege level; 

g) altering said second level secure memory 
in a distinctive fashion to reflect a determina- 
tion by said second privilege level of authen- 
ticity of said tangible element; and 

h) executing said protected software so long 
as said alteration of said second privilege lev- 
el secure memory is detected and denying 
said request if said alteration is not present 

2. A method as claimed in claim 1 wherein: 

said software (46) as distributed in said 
step c) has at least a portion encrypted; 

said second privilege level subsequent to 
performance of said step f) has access to a de- 
cryption key (AK); and 

said step h) comprises performing the fol- 
lowing steps on each subsequent request by said 
user to execute said protected software: 

responding, at said second privi- 
lege level, to check for said alteration of said sec- 
ond level secure memory, and, if said alteration 
is present, honouring said request by: 

a) initiating decryption of said protected soft- 
ware and storage of said decrypted software 
in said first privilege level secure memory, 

b) authorizing execution of said decrypted 
software by said first privilege level and ini- 
tiating operation of said first privilege level, 

and, if said alteration is not present, refus- 
ing said request 

3. A method as claimed in claim 1 wherein said pro- 
tected software (46) as distributed in said step c) 
includes a portion which is encrypted under a 
software key which itself is distributed encrypted 
under a different key, and in which said second 
privilege level has access to said different key so 
that said encrypted software key can be decrypt- 
ed by said second privilege level, and in which 
said step g) includes: 

1) decrypting said software key with said sec- 
ond key; and 

2) altering said second privilege level secure 
memory by writing said software key therein. 

4. A method as claimed in claim 3 in which said com- 



posite computing system is provided information 
with which to verify said tangible element and in 
which said step d) includes: 

1) providing said tangible element with phys'h 
5 cal security; 

2) providing said tangible element with elec- 
tronic storage having a destructive read func- 
tion; and 

3) storing a verifiable entity in said electronic 
10 storage. 

5. A method as claimed in claims 1-4, wherein exe- 
cution of said protected software (46) is only al- 
lowed if a condition is met, the method further 
15 comprising the steps of: 

a) providing to said coprocessor a statement 
of at least one condition; 

b) providing for storage in said secure mem- 
ory data associated with said condition along 

20 with storage of said software key; 

c) requiring said coprocessor to access said 
statement and said data prior to authorizing 
any use of said software key or said protected 
software; and 

25 d) further requiring said coprocessor to com- 

pare said statement and said data to deter- 
mine if said condition is met, and authorizing 
use if, and only if, said condition is met. 

30 6. A method as claimed in claim 5 wherein: 

e) said statement represents authorization for 
execution of said protected application no 
more than N times, wherein N is any integer; 
0 said secure memory data represents either 

35 a count C which is incremented each time said 

coprocessor authorizes execution of said pro- 
tected software or said integer N decrement- 
ed each time said coprocessor authorizes 
execution of said protected software; and 

40 g) said coprocessor either compares C to N or 

compares N to zero and said coprocessor au- 
thorizes execution if and only if N>C or N>0. 

7. The method of claim 5 wherein: 
45 e) said statement represents authorization for 

execution of said protected software until a 
current date and/or time reaches a terminal 
date and/or time; 

f) said secure memory data represents a ter- 
50 minat date and/or time; and 

g) said coprocessor compares a current data 
and/or time with said terminal date and/or 
time and authorizes execution if, and only if 
said current date and/or time precedes said 

55 terminal data and/or time. 



19 



37 



EP 0 266 748 B1 



38 



Patentanspruche 

1. Verfahren zur Sicherung geschutzter Software 
(46) gegen unbefugte Benutzung, ohne dad exi- 
st ierende Kanale zur Sof twareverteilung zerstort 5 
werden und gleichzeitig ohne daft die unbe- 
schrankte Herstellung von Sicherheitskopien der 
geschutzten Software durch den Benutzer ge- 
st6rt wird, wobei das Verfahren die Schritte um- 
faBt: 10 

a) Bereitstelien eines physisch sicheren Co- 
processors (15) und Koppeln des Coprozes- 
sors mit einem Wirtsrechner (host) (10) des 
Benutzers, um zwischen diesen Computern 
einen bidirektionalen Informationsaustausch 1$ 
mit dem Ziel zu unterhalten, ein zusammen- 
gesetztes Datenverarbeitungssystem zu er- 
zeugen, das den Wirtsrechner und den Co- 
prozessor umfaBt; 

b) Bereitstelien logischer Sicherheitsvorkeh- 20 
rungen fur den Coprozessor durch: 

1) Bereitstelien einerersten privilegier- 
ten Ebene, zur Ausfuhrung der geschutzten 
Software, die einen sicheren Speicher (151) 
der ersten Ebene und Operationsbefehle der 25 
ersten Ebene (152) enthalt, welche gegen Zu- 
griff und Veranderung durch den Benutzer 
gesichert sind; 

c) Verteilen der geschutzten Software (46) in 
einer Form, in welcher zumindest ein Teil 30 
durch den Wirtsrechner unausf uhrbar ist; 

d) Verteilen eines weiteren greifbaren, von 
der geschutzten Software getrennten Ele- 
mentes (20), das das Recht darstellt, die ge- 
schutzte Software auszufuhren; 35 

e) Herstellen des Zugriffs des zusammenge- 
setzten Datenverarbeitungssystems auf die 
geschutzte Software und auf das weitere 
greifbare Element; 

dadurch gekennzeichnet, daB : ao 
Schritt b) weiterhin den Schritt umfaBt: 
2)Bereitstellen einer zweiten privi- 
legierten Ebene zur Uberwachung des Bef ugnis- 
ses zur Ausfuhrung der geschutzten Software 
durch die erste privilegierte Ebene, enthaltend ei- 45 
nen sicheren Speicher der zweiten Ebene (153) 
und Operationsbefehle der zweiten Ebene (152), 
welche gegen Zugriff und Veranderung durch 
den Benutzer oder irgendeinen Autor von ge- 
schutzter Software gesichert sind; so 

dad die geschutzte Software, wie sie ent- 
sprechend Schritt c) verteilt wird, durch den Co- 
prozessor ausf uhrbar ist, aber nur uber die Er- 
machtigung durch die zweite privilegierte Ebene; 
und dad das Verfahren des weiteren die Schritte 55 
umfaBt: 

f) Uberprufen der Authentizitat des weiteren 
greifbaren Elementes durch den Coprozessor 



auf der zweiten privilegierten Ebene; 

g) Verandern des sicheren Speichers der 
zweiten Ebene auf eine besondere Weise, da- 
mit eine Feststellung der Authentizitat des 
greifbaren Elementes durch die zweite privile- 
gierte Ebene wiedergegeben wird und 

h) Ausfuhren der geschutzten Software so- 
lange, wie die Veranderung des sicheren 
Speichers der zweiten privilegierten Ebene 
erkannt wird und Ablehnen einer entspre- 
chenden Anforderung, wenn diese Verande- 
rung nicht vorhanden ist 

2. Verfahren nach Anspruch 1, dadurch gekenn- 
zeichnet, dad 

die Software (46), wie sie entsprechend Schritt c) 
verteilt wird, mindestens einen verschlusselten 
Abschnitt besitzt; 

die zweite privilegierte Ebene nachfolgend auf 
den Schritt f) Zugriff auf einen Dechiff rierschlus- 
sel (AK) hat, und 

Schritt h) bei jeder folgenden Anforderung des 
Benutzers nach Ausfuhrung der geschutzten 
Software die folgenden Schritte ausf u hit: 

Reagieren auf der zweiten privilegierten 
Ebene, um die Veranderung des sicheren Spei- 
chers der zweiten Ebene zu uberprufen, und 
wenn diese Veranderung vorhanden ist, Aner- 
kennen der Programmanforderung durch: 

a) Starten der Entschlusselung der geschutz- 
ten Software und Speicher n der entschlus- 
selten Software im sicheren Speicher der er- 
sten Ebene, 

b) Erteilen der Befugnis zur Ausfuhrung der 
entschiusselten Software durch die erste pri- 
vilegierte Ebene und Starten der Arbeit der er- 
sten privilegierten Ebene 

und wenn diese Veranderung nicht vor- 
handen ist, Ablehnen der Programmanforderung. 

3. Verfahren nach Anspruch 1, dadurch gekenn- 
zeichnet, daB die geschutzte Software (46), wie 
sie in Schritt c) verteilt wird, einen Abschnitt ent- 
halt, der mittels eines Softwareschlussels chif- 
friert worden ist, welcher wiederum selbst mit ei- 
nem anderen Schlussel verschlusselt verteilt 
wird und wobei die zweite privilegierte Ebene Zu- 
griff auf diesen anderen Schlussel hat, so dad 
der verschlusselte Softwareschlussel durch die 
zweite privilegierte Ebene entschlusselt werden 
kann, und wobei der Schritt g) enthalt: 

1) Entschlusseln des Softwareschlussels mit 
dem zweiten Schlussel und 

2) Verandern des sicheren Speichers der 
zweiten privilegierten Ebene dadurch, daB 
der Softwareschlussel dort eingeschrieben 
wird. 
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Verfahren nach Anspruch 3, dadurch gekenn- 
zeichnet, daR das zusammengesetzte Datenver- 
arbeitungssystem mit Informationen versehen 
wird t mit denen das greifbare Element uberpruft 
werden kann, und wobei der Schritt d) enthalt 5 

1) Versehen des greifbaren Elementes mit 
physischen Sicherheitsvorkehrungen; 

2) Versehen des greifbaren Elementes mit ei- 
nem elektronischen Speicher, der eine zersto- 
rende Lesefunktion besitzt, und 10 

3) Speichern einer uberprufbaren Einheit in 
dem elektronischen Speicher. 

Verfahren nach den Anspruchen 1 bis 4, dadurch 
gekennzeichnet, dafc die Ausfuhrung der ge- 15 
schutzten Software (46) nur dann gestattet wird, 
wenn eine Bedingung erf Gilt ist, wobei das Ver- 
fahren weiterhin folgende Schritte umfaBt: 

a) Bereitstellen einer Anweisung mit minde- 
stens einer Bedingung fur den Coprozessor ; 20 

b) Bereitstellen von mitdieser Bedingung ver- 
bundenen Daten zum Speichern in dem si- 
cheren Speicher zusammen mit dem Spei- 
chern des Softwareschlussels; 

c) Anweisen des Coprozessors, vor jeder Er- 25 
teilung einer Befugnis zur Nutzung des Soft- 
wareschlussels Oder der geschutzten Soft- 
ware auf die Anweisung und die Daten zuzu- 
greifen, und 

d) des weiteren Anweisen des Coprozessors, 30 
die Anweisung und die Daten zu vergleichen, 

urn daraus zu bestimmen, ob die Bedingung 
erf ullt ist, und Erteilen der Benutzungsbefug- 
nis nur dann, wenn die Bedingung erf ullt ist. 

35 

Verfahren nach Anspruch 5, dadurch gekenn- 
zeichnet, daft 

e) die Anweisung eine Benutzungsbefugnis 
zur Ausfuhrung der geschutzten Anwendung 
nicht hauf iger als N-mal reprasentiert, wobei ao 
N eine ganze Zahl ist; 

f) die Daten des sicheren Speichers entweder 
einen Zahlerstand C reprasentieren, der je- 
des Ma! erhoht wird, wenn der Coprozessor 

die Befugnis zur Ausfuhrung der geschutzten 45 
Software erteilt, Oder aber die ganze Zahl N, 
die jedes Mai verringert wird, wenn der Copro- 
zessor die Befugnis zur Ausfuhrung der ge- 
schutzten Software erteilt, und 

g) der Coprozessor entweder C mit N oder N 50 
mit Null vergleicht und daR der Coprozessor 

die Befugnis zur Ausfuhrung nur dann erteilt, 
wenn N > C oder N > 0 ist. 

Verfahren nach Anspruch 5, dadurch gekenn- 55 

zeichnet, daR 

e) die Anweisung eine Benutzungsbefugnis 
zur Ausfuhrung der geschutzten Software bis 



zu einem Zeitpunkt reprasentiert, an dem das 
momentane Datum und/oder die Zeit ein Be- 
endigungsdatum und/oder eine Beendi- 
gungszeit erreicht; 

f) die Daten des Sicherungsspeichers ein Be- 
endigungsdatum und/oder eine Beendh 
gungszeit reprasentieren, und 

g) der Coprozessor das momentane Datum 
und/oder die Zeit mit dem Beendigungsdatum 
und/oder der Beendigungszeit vergleicht und 
die Befugnis zur Ausfuhrung nur dann erteilt, 
wenn das momentane Datum und/oder die 
Zeit vor dem Beendigungsdatum und/oder 
der Beendigungszeit liegen. 



Revendications 

1. Procede pour interdire toute utilisation non auto- 
risee d'un logiciel protege (46) sans perturber les 
circuits de distribution de logiciels existants et 
sans entraver la liberie de creation, par les utilh 
sateurs, d'un nombre illimite de copies de sauve- 
garde du logiciel protege, ledit procede compre- 
nant les etapes consistant a : 

a) fournir a I'utilisateur un coprocesseur pro- 
tege physiquement (15) et coupler ledit copro- 
cesseur a un processeur central utiiisateur 
(10) pour assurer une communication bidirec- 
tionnelle entre les deux, afin de creerun sys- 
teme de traitement composite comprenant le- 
dit processeur central et ledit coprocesseur, 

b) assurer la protection logique du dit copro- 
cesseur en : 

1) prevoyant un premier niveau de pri- 
vilege incluant une memoire protegee de pre- 
mier niveau (151) et des instructions d'exploi- 
tation de premier niveau (152), protege contre 
tout acces ou alteration par ledit utiiisateur, 
pour executer le logiciel protege; 

c) distribuer le logiciel protege (46) sous une 
forme sous laquelle au moins une partie est 
inexecutable par ledit processeur central; 

d) distribuer un autre element tangible (20) 
distinct du dit logiciel protege representant un 
droit d'execution du dit logiciel protege; 

e) assurer I'acces au systeme de traitement 
composite par ledit logiciel protege et ledit au- 
tre element tangible; 

caracterise en ce que: 

I'etape b) comprend, de plus, I'etape consistant a: 
2) prevoir un second niveau de privilege 
incluant une memoire protegee de second niveau 
(153) et des instructions Sexploitation de second 
niveau (152), proteg6 contre tout acces ou alte- 
ration par ledit utiiisateur ou tout auteur de logi- 
ciels proteges, pour contrdler Tautorisation 
d'execution du dit logiciel protege par ledit pre- 
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mier niveau de privilege; 
et en ce que, au cours de I'etape c), te logiciet pro- 
tege distribue est executable par ledit co proces- 
ses uniquement avec I'autorisat ion du d it second 
niveau de privilege; 5 
et en ce que le procede comprend, de plus, les 
etapes consistant a: 

f) faire verifier I'authenticite du dit autre ele- 
ment tang ible par ledit coprocesseur au dit se- 
cond niveau de privilege; 10 

g) modifier ladite memo ire protegee de dit se- 
cond niveau de maniere distinctive pour refle- 
ter la determination par ledit second niveau de 
privilege de I'authenticite du dit element tan- 
gible; et 15 

h) executer ledit logiciel protege tant que ladi- 
te modification de ladite memoire protegee de 
second niveau est detectee, et rejeter ladite 
demande d'execution si ladite modification 
n'est pas presents. 20 

2. Procede selon la revendication 1, dans lequel : 
ledit logiciel (46), distribue conformement a I'eta- 
pe c), comprend au moins une partie cryptee; 

ledit second niveau de privilege a, a Tissue de 25 
I' execution de ladite etape f), acces a une de de 
dechiffrage (AK); et 

ladite etape h) comprend ['execution des etapes 
suivantes a chaque demande ulterieure par I'uti- 
lisateur d'execution du dit logiciel protege: 30 

repondre, au dit second niveau de privile- 
ge, pour verifier ladite modification de ladite me- 
moire protegee de second niveau, et, si la modi- 
fication est effective, honorer ladite demande 
en: 35 

a) Ian cant le dechiffrage du dit logiciel prote- 
ge et la memorisation du dit logiciel dechiffre 
dans ladite memoire protegee de premier ni- 
veau, 

b) autorisant ('execution du dit logiciel dechif- 40 
fre par ledit premier niveau de privilege, et en 
langant I'exploitation du dit premier niveau de 
privilege, 

et rejeter ladite demande si ladite modifi- 
cation n'est pas effective. 45 

3. Procede selon la revendication 1 , dans lequel le- 
dit logiciel protege (46), distribue conformement 
a I'etape c), comprend une partie cryptee selon 

une cle logicielle qui est elle-meme distribute 50 
cryptee selon une autre de, et dans lequel ledit 
second niveau de privilege a acces a ladite autre 
cle af in de permettre le dechiffrage de ladite cle 
logicielle cryptee par ledit second niveau de pri- 
vilege, et dans lequel ladite etape g) comprend 55 
les etapes consistant a: 

1) dechiffrer ladite de logicielle a Taide de la- 
dite seconde de; et 



2) modifier ladite memoire protegee de se- 
cond niveau en chargeant ladite de logicielle 
dans celle-ci. 

4. Procede selon la revendication 3, dans lequel le- 
dit systeme de traitement composite dispose d 'in- 
formations qui lui permettent de verifier ledit ele- 
ment tangible, et dans lequel ladite etape d) 
comprend les etapes consistant a: 

1) assurer la protection physique du dit ele- 
ment tangible; 

2) prevoir, dans ledit element tangible, une 
memoire electronique ayant une fonction de 
lecture destructive; et 

3) memoriser une entite verifiable dans ladite 
memoire electronique. 

5. Procede selon I'une quelconque des revendica- 
tions 1 a 4, dans lequel I'execution du dit logiciel 
protege (46) n'est autorisee que lorsqu'une 
condition est remplie, le procede comprenant, de 
plus, les etapes consistant a : 

a) fournir au dit coprocesseur au moins une 
condition sous forme ^instruction; 

b) prevoir la memorisation dans ladite memoi- 
re protegee de donnees associees a ladite 
condition lors de la memorisation de ladite cle 
logicielle; 

c) demand er au coprocesseur d'acceder a la- 
dite instruction et aux dites donnees avant 
d'autoriser ('utilisation de ladite cle logicielle 
ou dit logiciel protege; et 

d) demander au coprocesseur de comparer 
ladite instruction et les dites donnees pour de- 
terminer si ladite condition est remplie, et 
n'autoriser I'utilisation que si et seulement si 
ladite condition est remplie. 

6. Procede selon la revendication 5, dans lequel : 

e) ladite instruction represente I'autorisation 
d'executer ladite application protegee au plus 
N fois, ou N est un nombre entier, 

f) les donnees dans ladite memoire protegee 
represente soit un compte C increments a 
chaque fois que le coprocesseur autorise 
I'execution du dit logiciel protege, soit ledit en- 
tier N decrements a chaque fois que le copro- 
cesseur autorise I'execution du dit logiciel pro- 
tege; et 

g) ledit coprocesseur compare C a N, ou 
compare N a zero, et autorise ladite execution 
si et seulement si N>C ou N>0. 

7. Procede selon la revendication 5, dans lequel : 

e) ladite instruction represente I'autorisation 
d'executer ledit logiciel protege jusqu'a ce 
qu'une date et/ou une heure courante(s) at ten 
gne(nt) une date et/ou une heure limite(s); 
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f) les dites donnees dans la memoire protegee 
represented una date et/ou una heure limi- 
te(s); et 

g) ted it coprocesseur compare una date/ou 

una heure courante(s) avec ladite (les dites) s 
date et/ou heure limtte(s) et autorise ladite 
execution si et seulement si ladite (les dites) 
date et/ou heure courante(s) precede (nt) ladi- 
te (les dites) date et/ou heure limite(s). 
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